Компания VMware сегодня сделала доступной для скачивания новую версию своей платформы виртуализаци VMware vSphere 5. Надо сказать, что подробности о vSphere 5 появились довольно давно, затем было объявлено, что продукт можно будет скачать 22 августа, но только сегодня, 25 августа, VMware vSphere 5 можно наконец-то скачать.
Напоминаем, что для бесплатного гипервизора VMware ESXi 5 можно использовать максимально 32 ГБ сконфигурированной памяти запущенных виртуальных машин на данном хосте.
Старые версии VMware vSphere по-прежнему остаются доступными для скачивания: 4.1, 4.0
Отдельно можно скачать продукты семейства VMware vSphere на каждой из страниц конкретного продукта (за ссылки спасибо Duncan'у Epping'у):
Надо сказать, что не все компоненты решения доступны для загрузки. Например, VMware vCenter Server Appliance будет доступен для скачивания в течение нескольких дней.
Начать думать о миграции с VMware ESX / ESXi 4.x на VMware ESXi 5 можно с просмотра вот этого видео:
Про VMware Data Recovery 2.0 только нет пока заметки. Вы наверное заметили, что пока нельзя скачать VMware vCloud Director 1.5, VMware Site Recovery Manager 5 и VMware View 5. Это только пока - доступность этих продуктов для скачивания ожидается 1 сентября.
Кстати, по поводу покупки VMware vSphere 5 обращайтесь к нам, в компанию VMC. У нас обязательно будут предложения, от которых вы не сможете отказаться.
В новой версии платформы виртуализации VMware vSphere 5 появилась интересная возможность - Host Cache. Это механизм, который позволяет пользователю vSphere 5 выделить определенное место на локальных дисков хост-сервера ESXi (лучше всего, если это будут SSD-диски) для хранения свопируемых страниц памяти виртуальных машин. Это позволяет существенно увеличить скорость работы файлов подкачки виртуальных машин (vswp), так как они находятся на локальных высокопроизводительных дисках, и, соответственно, увеличить общее быстродействие инфраструктуры виртуализации.
Хорошая и развернутая статья о Swap to Host cache в VMware vSphere 5 есть у Duncan'а Epping'а, а здесь мы приведем основные ее выдержки.
Прежде всего, после установки VMware ESXi 5 хост может не увидеть локальные SSD-хранилища как пригодные для хранения кэша виртуальных машин. Для этого есть вот такой хак от Вильяма Лама. Далее мы идем на вкладку Configuration в vSphere Client и выбираем секцию Host Cache Configuration:
Тут мы можем задать объем дискового пространства на локальном томе VMFS, который мы можем использовать для файлов подкачки виртуальных машин, работающих на этом хосте. После включения этой возможности на этом локальном томе VMFS появится куча vswp-файлов, в которые гостевые ОС виртуальных машин этого хоста будут складывать свои свопируемые страницы памяти.
Поскольку эти своп-файлы находятся только на этом хосте, то при миграции vMotion содержимое страниц памяти из этих файлов надо скопировать на другой хост в его Host Cache или в vswp-файл в папке с виртуальной машиной на общем хранилище. Это, само собой, увеличивает время на миграцию vMotion, и это надо учитывать.
Что касается надежности при отказе хост-сервера, то тут нет проблем - так как при отказе хоста все равно его виртуальные машины перезапускаются на других хостах, то данные из файлов подкачки для ВМ уже не будут нужны.
Наблюдать за использованием Host Cache можно из VMware vCenter 5 с помощью метрик "Swap in from host cache" и "Swap out to host cache" (а также "rate..."). В результатах вывода консольной утилиты esxtop это метрики LLSWR/s и LLSWW/s.
Что будет когда место на локальном свопе Host Cache закончится? Сервер ESXi начнет копировать страницы в обычный vswp-файл, который находится в папке с виртуальной машиной, что само собой повлияет на производительность. Кстати, размер Host Cache можно изменять при работающем хосте и виртуальных машинах, поэтому лучше увеличивать его вовремя, да и в целом не доводить до большого свопа виртуальных машин (то есть, правильно сайзить хосты по памяти для ВМ). К примеру, Duncan рекомендует 128 ГБ SSD-диски в RAID-1 для 128 ГБ оперативной памяти хоста.
Альтернатива Host Cache - это задать параметр VM swapfile location для виртуальной машины в ее настройках, указав, например, локальный SATA или SSD-диск (можно использовать и быстрые общие хранилища).
Как вы знаете, компания VMware в ближайшее время намерена выпустить не только VMware vSphere 5, но и новую версию продукта для создания катастрофоустойчивой инфраструктуры VMware Site Recovery Manager 5.
Помимо того, что мы уже описывали о VMware SRM 5, появился расширенный список возможностей, который приведен ниже:
Возможности Sphere Replication – техника, позволяющая делать host-based репликацию для виртуальных машин в небольших компаниях (поддерживаются не только общие тома, но и локальные хранилища серверов ESXi). Вот некоторые ограничения технологии:
Требует vSphere 5.
Управляется напрямую из vSphere client.
Смонтированные ISO-шки и Floppy-ки не реплицируются.
Машины в состоянии Powered off/Suspended не реплицируются.
Некритичные файлы тоже не реплицируются (swap files, dumps, logs и т.д.).
Виртуальная машина может иметь снапшот на защищаемом сайте, но он будет применен (смерджен) на резервном.
Физические тома RDM не поддерживаются (но виртуальные поддерживаются).
Не поддерживаются также следующие ВМ: с включенной Fault Tolerance, Linked Clones и VM Templates.
Первичная копия ВМ может быть сделана на оффлайн-носитель (например, переносной диск) - что уменьшаяет требования к каналу репликации.
Поддерживает технику создания консистентных виртуальных машин на резервном сайте (на уровне файлов, но не на уровне приложений).
Включена в обе редакции SRM: Standard и Enterprise Editions.
vSphere Replication можно использовать только в продукте SRM 5.
Улучшения масштабируемости:
До 1000 защищаемых ВМ (как и в SRM 4.1).
500 защищаемых ВМ в одной protection group (как и в SRM 4.1)
Количество Protection Groups - 250 (ранее 150 в 4.1).
30 одновременно исполняемых планов восстановления после сбоя (ранее - всего 3).
Функции Planned Migration – это выключение виртуальных машин на основном сайте, их репликация на резервный и последующее включение их там. То есть это - плановый переезд датацентра или части инфраструктуры. В этом случае сохраняется полная консистентность.
Функции Failback – теперь можно в случае аварии, восстановления на резервном сайте и последующего восстановления основного сайта, можно снова переехать на основной сайт. Делается это за счет перенаправления репликации и реверсного исполнения плана восстановления.
Улучшения интерфейса и юзабилити:
Оба датацентра теперь видятся и управляются без vCenter linked mode.
Изменения IP-адресации для ВМ во время восстановления теперь могут быть введены в GUI, без геморроя
Заглушки для резервных ВМ за резервном сайте теперь имеют уникальную иконку, чтобы идентифицировать их как заглушки, а не производственные ВМ.
Отчеты теперь включают user ID, который инициировал операции Failover или DR test.
Отчеты включают в себя больше информации о шагах по работе с дисковыми массивами (включая device friendly names)
IPv6 Support – полностью поддерживается.
IP Customization performance – заметное улучшение по скорости преобразования IP-адресов.
In guest callouts – теперь можно выполнить скрипт в ВМ, выполнить скрипт на сервере SRM или сделать брейкпоинт (точку останова) для вывода сообщения во время исполнения плана восстановления.
Новый API для обоих частей - Protected и Recovery Sides – новые команды для интеграции со сторонними приложениями и системами (на базе SOAP).
Улучшение связности – теперь есть 5 priority groups для каждого плана восстановления. Каждая группа должна полностью выполниться в рамках DR-плана, пока не будет осуществлен переход к следующей группе. В рамках каждой группы можно создавать зависимости (аналогично зависимостям в службах Windows). То есть, например, машина не начнет восстанавливаться, пока все зависимые для нее компоненты не будут восстановлены (но все это только в рамках одной группы приоритетов).
Licensing – теперь есть 2 издания SRM: Standard and Enterprise. Оба издания абсолютно идентичны. Единственная разница - это то, что в издании SRM Standard есть ограничение на 75 виртуальных машин на одной площадке. Здесь отчетливо видно, что цена в $195 за виртуальную машину для издания Standard (а значит, и для среднего и малого бизнеса) - это попытка конкурировать с продуктом Veeam Backup and Replication 5, который еще со своей первой версии умеет делать репликацию виртуальных машин между площадками.
В целом, конечно список улучшений весьма обширен. А что касается конкуренции VMware SRM 5 с Veeam Backup and Replication 5 - в плане репликации, последний пока выигрывает, так как имеет меньше функциональных ограничений (о произодительности пока сказать нельзя - SRM 5 еще не вышел). Ожидается, что VMware SRM 5 будет доступен для загрузки после 22 августа.
Таги: VMware, SRM, Update, vSphere, Replication, Veeam, Backup, HA, VMachines
Компания VMware в июле 2011 года объявила о доступности новых версий целой линейки своих продуктов для облачных вычислений, среди которых находится самая технологически зрелая на сегодняшний день платформа виртуализации VMware vSphere 5.0.
Мы уже рассказывали об основном наборе новых возможностей VMware vSphere 5.0 неофициально, но сейчас ограничения на распространение информации сняты, и мы можем вполне официально рассказать о том, что нового для пользователей дает vSphere 5.
Как вы знаете, VMware vSphere 5 будет построена только на базе гипервизора VMware ESXi (а ESX больше не будет) и выйдет уже в этом году, поэтому мы публикуем серию заметок о том, как перейти на ESXi с ESX (вот тут - раз и два).
Сегодня мы поговорим о таком различии, как Scratch Partition в ESXi. Scratch Partition - это специальный раздел на хранилище для хост-сервера, который не обязательно, но рекомендуется создавать. Он хранит в себе различную временную информацию для ESXi, как то: логи Syslog'а, вывод команды vm-support (для отправки данных в службу поддержки VMware) и userworld swapfile (когда он включен). Он создается, начиная с vSphere 4.1 Update 1 автоматически, и, если есть возможность, на локальном диске.
Так как данный раздел является необязательным, то в случае его отсутствия вся перечисленная информация хранится на ramdisk хост-сервера (который, кстати, отъедает память - 512 MB). И, так как это ramsidk, после перезагрузки эта информация (если у вас нет scratch partition) очищается. Поэтому неплохо бы этот раздел, все-таки, создать.
По умолчанию, этот раздел создается в системе vfat и составляет 4 ГБ. Это много. Почему так много? Объяснение такое, что местечко оставлено под будущие версии ESXi. Этот раздел может размещаться локально или на SAN-хранилище. При этом его могут использовать несколько хостов ESXi одновременно, поэтому рекомендуется сделать его гигов 20. Но для каждого должна быть своя locker-директория на этом разделе.
Через vSphere Client scratch partition настраивается так:
Соединяемся с хостом ESXi из vSphere Client.
Переходим на вкладку Configuration.
Переходим в категорию Storage.
Нажимаем правой кнопкой на datastore и выбираем Browse.
Создаем уникальную директорию для хоста ESXi (например, .locker-ESXiHostname)
Закрываем Datastore Browser.
Переходим в категорию Software.
Нажимаем Advanced Settings.
Переходим в раздел ScratchConfig.
Устанавливаем в качестве значения ScratchConfig.ConfiguredScratchLocation директорию, которую только что создали, например:
/vmfs/volumes/DatastoreName/.locker-ESXiHostname
Нажимаем OK.
Перезагружаем ESXi.
Все это можно настроить и при автоматизированном развертывании VMware ESXi через kickstart. А можно и через vCLI и PowerCLI. О том, как это сделать, читайте в KB 1033696.
Мы уже писали о ставших официально известными подробностях о новой версии платформы виртуализации VMware vSphere 5.0. С мной поделились интересной ссылкой на подробное описание новых функций vSphere 5.0, которое сделано, судя по всему, на базе Release Candidate версии продукта.
Поскольку я не нахожусь под действием NDA и не участвую в бета-программе, я могу поделиться с вами основными ключевыми возможностями vSphere 5.0 (приведены лишь ключевые особенности - остальные по ссылке выше):
1. Платформа vSphere 5.0 будет построена только на базе гипервизора ESXi - без возможности установки ESX. Сервер управления VMware vCenter 5.0 будет поддерживать управление хостами ESXi 5.0, ESX/ESXi 4.x и ESX/ESXi 3.5.
2. VMware vSphere Auto Deploy - полная поддержка автоматизированного развертывания хостов ESXi.
3. Новые возможности виртуальных машин - 32 виртуальных процессора (vCPU), 1 TB RAM, 3D-акселерация для поддержки Windows Aero, UEFI virtual BIOS, поддержка устройств USB 3.0 (пока только для Linux-систем и только для проброса через vSphere Web Client - напрямую к хосту нельзя). Устройства USB 2.0 теперь поддерживаются к пробросу в виртуальные машины через vSphere Client или vSphere Web Client.
6. Dynamic Resource Scheduling (DRS) for Storage - эта давно ожидаемая функция платформы виртуализации, которая позволит автоматически выравнивать нагрузку на системы хранения путем динамического перемещения работающих виртуальных машин между хранилищами (сейчас это можно сделать вручную за счет Storage VMotion). Пользователи смогут определять группы Datastor'ов (они зовутся Storage Pods), которые будут использоваться для балансировки по хранилищам на базе их заполненности. Предполагается, что это повысит автоматизацию датацентров. Вроде как присутствует и генерация рекомендаций по балансировке и Initial Placement на базе параметров IO.
7. Policy-driven storage delivery - политики размещения виртуальных машин на хранилищах на базе правил, задаваемых администратором. Это позволит регулировать качество обслуживания систем со стороны хранилищ и автоматически определять наилучшее место хранения виртуальных машин.
8. Файловая система VMFS 5.0.
9. Accelerator - новая технология кэширования данных виртуальных ПК для VMware View, увеличивающая их производительность.
10. Полный контроль за iSCSI адаптерами (программными и аппаратными) из графического интерфейса.
12. Swap to SSD - для хранилищ администратор будет назначать тэги, наиболее производительные хранилища SSD будет рекомендовано использовать для хранения swap-файлов в целях ускорения быстродействия.
13. Поддержка LUN для VMFS томов размером более 2 ТБ.
14. Поддержка технологии Storage vMotion для виртуальных машин со снапшотами.
15. Enhanced Network I/O Control (на уровне виртуальных машин) - эта возможность будет позволять резервировать часть канала для приоритетных задач в кластере HA/DRS на случай его перегрузки. Актуально это будет для сетей 10G, где канал шире, а вот физических адаптеров значительно меньше.
16. ESXi Firewal - новый сетевой экран с фильтрами по диапазонам IP для каждой службы.
17. vSphere Web Client на базе технологии Adobe Flex с большим спектром возможностей. Старый vSphere Client под Windows также останется.
18. vCenter Server Appliance - виртуальный модуль на базе Linux с предустановленной службой vCenter. О CTP-версии данного продукта мы уже писали.
19. Enhanced logging support - поддержка логирования на удаленные серверы, в том числе на несколько серверов от одного источника по безопасному каналу SSL. Для vSphere Client будет плагин vSphere syslog listener, который позволит настраивать данную функциональность.
20. Fault Domain Manager - специализированный модуль управления высокой доступностью VMware HA, который еще больше увеличивает уровень доступности виртуальных машин. Кроме того, теперь все хост-серверы VMware ESXi в кластере являются первичными узлами (primary nodes) - то есть кластер HA переживет любое число отказов.
21. Host-based replication for Site Recovery Manager - возможность репликации виртуальных машин на уровне хостов а не SAN-хранилищ (как делается сейчас). То есть, поддержка технологии репликации со стороны СХД будет не нужна, репликация будет работать в асинхронном режиме со стороны хост-серверов. По-сути, это аналог репликации виртуальных машин в продукте Veeam Backup and Replication 5, которая сейчас активно используется в производственной среде многими компаниями для защиты данных виртуальных машин и наиболее быстрого восстановления работоспособности сервисов (показатели RTO).
Выход VMware vSphere 5.0 запланирован на второе полугодие 2011 года. Но скорее всего пятая версия платформы выйдет до VMworld 2011, который начнется 29 августа.
Естественно, информация неофициальная и список новых возможностей VMware vSphere 5.0 может быть изменен в любой момент. Но вот что будет точно - так это отсутствие гипервизора ESX - так что всем организациям пора задуматься о плане перехода на "тонкую" платформу ESXi 5.0.
Механизм VMware High Availability (HA) в VMware vSphere позволяет автоматически перезапустить виртуальные машины отказавшего сервера в кластере с общего хранилища в случае сбоя. При настройке кластера VMware HA можно использовать несколько расширенных настроек (HA Advanced Settings), которые позволяют настроить его работу наиболее гибко.
Таги: VMware, HA, ESX, ESXi, Bugs, vSphere, VI, VMachines, Обучение
Как обычно, Duncan Epping написал отличный пост об использовании памяти виртуальными машинами на хостах VMware ESX. Постараемся объяснить это на русском языке. Итак, если открыть вкладку Summary в vSphere Client для виртуальной машины, мы увидим вот такую картину:
Здесь есть 2 главных параметра:
Memory - это то количество оперативной памяти, которое вы выделили виртуальной машине при создании. За это количество гостевая ОС не выйдет при ее использовании. Это же количество памяти вы увидите в гостевой ОС.
Memory Overhead - это количество памяти, которое может потребоваться гипервизору на поддержание работы виртуальной машины сверх используемой памяти (т.е. расчетные накладные расходы на виртуализацию, но не текущие).
Далее мы видим панель Resources, здесь есть такие показатели:
Consumed Host Memory - это количество физической памяти хоста ESX, выделенной виртуальной машине. Обычно это значение не больше значения Memory на предыдущей картинке. Но может быть и больше, поскольку Consumed Host Memory включает в себя и Memory Overhead, но не с картинки выше, а реально используемый гипервизором Overhead (о котором будет идти речь ниже). И важный момент - счетчик Consumed для Memory на вкладке "Performance" не включает в себя Overhead.
Active Guest Memory - это количество памяти, которое по мнению гипервизора VMkernel активно используется гостевой операционной системой. Вычисляется этот параметр на базе статистических показателей. То есть, если ОС не очень активно использует память, то можно ей ее немного подрезать в условиях нехватки ресурсов.
Теперь идем на вкладку "Resource Allocation". Здесь все немного сложнее:
Появляются вот такие показатели:
Для Host Memory (видим, что это 2187 МБ = сконфигурированная память 2048 МБ + Overhead):
Consumed - это, опять-таки, объем потребляемой виртуальной машиной физической памяти хоста ESX (постоянно меняется). И он включает в себя накладные расходы гипервизора по памяти.
Overhead Consumption - это текущий объем затрат памяти на поддержание виртуальной машины (здесь 42 МБ в отличие от расчетного в 110 МБ)
А формула такова: Consumed = Private + Overhead Comsumption
Для Guest Memory (2048 МБ сконфигурировано в настройках):
Private - это объем памяти физически хранимый хостом для виртуальной машины (см. формулу выше).
Shared - это объем памяти, который отдается другим виртуальным машинам от разницы между сконфигурированным объемом (Configured Memory) и потребляемым (Consumed). Суть в том, что ОС Windows при загрузке очищает всю память виртуальной машины, но потом эти пустые страницы приложениями не используются. Поэтому гипервизор отдает их другим ВМ, пока ВМ, владеющая памятью не потребует их. Эти страницы и есть Shared. Как мы видим, Private + Shared = Guest Memory.
Swapped - это объем памяти, ушедший в файл подкачки vswp. То есть это не файл подкачки Windows, а файл подкачки в папке с виртуальной машиной. Само собой этот показатель должен быть нулевым или совсем небольшим, поскольку своппинг, который делает ESX (а точнее VMkernel) - это плохо, т.к. он не знает (в отличие от Windows), какие страницы нужно складывать в своп, поэтому кладет все подряд.
Compressed - это объем памяти, который получен после сжатия страниц с помощью механизма Memory Compression (то есть, хранимый в VM Compression Cache).
Ballooned - это объем памяти, который забрал balloon-драйвер (vmmemctl), чтобы отдать ее другим нуждающимся виртуальным машинам.
Unaccessed - это память, к которой гостевая ОС ни разу не обращалась (у Windows - это близко к нулю, так как она обнуляет память при загрузке, у Linux должно быть как-то иначе).
Active - опять-таки, активно используемая память на основе статистики гипервизора.
На хорошем и производительном хосте VMware ESX метрики Compressed, Ballooned, Unaccessed - должны быть около нуля, так как это означает что машины не борются за ресурсы (то есть не сжимают страницы и не перераспределяют память между собой). Ну и, конечно, если показатель Active маленький, стоит задуматься об урезании памяти (но сначала посмотрите в гостевую ОС, она лучше знает, чем гипервизор, все-таки).
Worst Case Allocation - это сколько будет выделено виртуальной машине при самом плохом раскладе (максимальное использование ресурсов), то есть вся память будет использоваться, да еще и накладные расходы будут (т.е., Configured + максимальный Overhead).
Overhead Reservation - это сколько зарезервировано памяти под Overhead гипервизором.
Многим пользователям платформы виртуализации VMware vSphere / ESX известен такой механизм оптимизации работы виртуальных машин с оперативной памятью как Memory Ballooning (о нем хорошо написано в документе "Understanding Memory Resource Management in VMware ESX Server"). Если вкратце - то это техника гипервизора по работе с оперативной памятью, которая позволяет запустить на хосте ESX виртуальные машины, совокупная выделенная память которых больше суммарной памяти хоста.
Достигается это за счет использования драйвера vmmemctl.sys, поставляемого вместе с VMware Tools. Он позволяет "надуть" шар внутри гостевой ОС (balloon), который захватывает физическую память, выделенную этой ОС, и отдает ее другим гостевым операционным системам, которые в ней нуждаются. Этот balloon не позволяет гостевой ОС производить работу приложений с данной областью памяти, поэтому если им потребуется дополнительная память - она будет уходить в гостевой своп. Это более правильный подход, чем свопировать гостевую ОС в файл подкачки vswp на томе VMFS, поскольку операционная система сама лучше разбирается, что и когда ей класть и доставать из свопа (соответственно, быстродействие выше).
Недавно у известного блоггера Дункана Эппинга спросили вот про такой интересный случай. Пользователь запустил команду esxtop на странице с показателями памяти для виртуальных машин и получил вот такой результат:
Собственно, какова ситуация, если смотреть по счетчикам на картинке:
Глобальные статистики:
1393 Free -> Сейчас 1393 МБ физической памяти хоста доступно
High State -> Состояние, в котором считается, что хост не испытывает проблем с памятью
SWAP /MB 146 Cur -> 146 МБ находится в свопе
SWAP /MB 83 Target -> Целевой объем памяти, который должен быть в свопе - 83 МБ
0.00 r/s -> Из свопа ничего не читается
0.00 w/s -> В своп ничего не пишется
Статистики виртуальной машины (обведено красным):
MCTLSZ 1307.27 -> Объем физической памяти гостевой системы, заполненной balloon-драйвером - 1307.27 МБ
MCTLTGT 1307.27 -> Объем физической памяти гостевой системы, который будет сохарнен balloon-драйвером - 1307.27 МБ
SWCUR 146.61 -> В свопе находится 146.61 МБ данных.
SWTGT 83.75 -> Целевой объем памяти, который который должен быть в свопе - 83.75 МБ
С одной стороны хост ESX выглядит типично overcommited, то есть balloon-драйвер раздулся. С другой же стороны, сервер VMware ESX находится в состоянии High State, что означает, что свободно более 6% памяти и проблем с ней нет (кроме того, ничего не пишется и не читается из файла подкачки). Казалось бы, здесь есть некоторое противоречие - если у хоста нет проблем с памятью, то почему balloon до сих пор надут и не сдувается?
Посмотрим на соотношение свободной памяти хоста ESX и размер области, занятой balloon'ом: 1393 МБ и 1307.27 МБ, соответственно. Они приблизительно равны. Это означает, что при сдутии balloon'а гостевая ОС, в которой он был надут, начнет отъедать физическую память хоста ESX (да и еще выгружать своп). Это приведет к тому, что объем доступной памяти хоста ESX упадет и он снова окажется в ситуации, когда необходимо снова надувать balloon.
То есть VMware ESX (и драйвер vmmemctl) не делают резких движений, растут и сдуваются постепенно, делая оглядку на то, какая ситуация может получиться.
Большинству пользователей виртуальной инфраструктуры VMware vSphere известны такие параметры как Limit, Reservation и Shares для пулов ресурсов (Resource Pool) в пределах кластеров VMware DRS и отельных хостов ESX. Именно этими тремя параметрами определяется потребление виртуальными машинами оперативной памяти и процессорных ресурсов хоста VMware ESX. Таги: VMware, vSphere, Resources, ESX, HA, DRS
Компания VMware уже почти готова к выпуску продукта для виртуализации корпоративных настольных ПК VMware View 4.5. Этот продукт является продолжателем платформы VMware View 4, несет в себе полностью переработанный GUI и имеет множество новых интересных возможностей.
Вот приблизительный список того, что можно ожидать в VMware View 4.5:
Virtual Profiles - это профили пользователей виртуальных ПК на базе программного продукта от компании RPO Software, приобретенного VMware. Эта возможность позволяет "отвязать" профиль пользователя от операционной системы Windows, что значительно повысит гибкость решения.
VMware View Client with Local Mode - возможность "выгружать" десктопы пользователей с серверов VMware vSphere и исполнять их локально в виртуальной машине на базе ПО VMware Workstation, работающей поверх хостовой ОС вашего ПК (клиентского гипервизора CVP пока не будет).
ThinApp 4.5 with Application Entitlement - возможность привязки виртуализованных приложений к пулам виртуальных ПК.
Tiered Storage (ярусное хранение виртуальных машин) - отличная возможность управлять хранением данных различного типа на хранилищах (datastores) разной категории.
Full Sysprep support - поддержка механизма автоматизированного развертывания Sysprep.
Disposable Disk technology - возможность определить временные папки (temp/swap) в ваших виртуальных ПК и автоматически очищать их.
Snapshot support for Linked Clones - так называемый "плавающий" пул (Floating Pool).
Role Based Administration - наконец-то, администрирование через View Manager на базе ролей.
Kiosk Mode Desktop Pools - конфигурация десктопов на уровне устройств.
Native Mac OS client - можно управлять своим виртуальным ПК с компьютера с Apple Mac OS.
Web Download Portal - возможность скачивания клиентского ПО через Web.
Переработанный Dashboard - удобный интерфейс (на базе Adobe Flex) и более понятное логирование событий.
Более подробно о VMware View 4.5 можно будет узнать уже в ближайшем будущем. Не отключайтесь!
Многим пользователям VMware должна быть известна техника Memory Overcommit, которая представляет собой, по-сути, совокупность трех технологий:
Memory Balooning - выдергивание неиспользуемой памяти из гостевой системы и ее передача нуждающимся виртуальным машинам
Технологии использования файлов подкачки (swap) и Memory Compression (появится в следующих релизах vSphere)
Transparent Page Sharing - техника поиска и удаления дубликатов страниц памяти виртуальных машин (остаются только ссылки на них)
Сегодня мы как раз и поговорим о последней технологии - Transparent Page Sharing. По статистике она позволяет экономить до 15% и более оперативной памяти хост-сервера VMware ESX, что, естественно, ведет к большему (по сравнению с другими платформами) коэффициенту консолидации виртуальных машин.
Отчасти, именно благодаря Transparent Page Sharing, продуктам компании VMware удавалось выгодно отличаться от конкурирующих платформ виртуализации. Page Sharing работает со страницами памяти размером 4 килобайта, что практически не влияет на производительность сервера виртуализации.
Так вот, согласно вот этой статье Alessandro Perilli, операционные системы Windows 7 и Windows Server 2008 R2 уже поддерживают технологию Large Memory Pages, которая позволяет использовать страницы памяти размером 2 мегабайта (чувствуете разницу на 2 с половиной порядка?). Кроме того, эта технология поддерживается и в процессорах Intel Nehalem, а также последних моделях AMD Opteron. Так вот исследование показало, что большие страницы памяти Large Memory Pages работают на 20% производительнее маленьких на новом железе. Что позволяет говорить о том, что эта техника использования памяти в операционных системах скоро станет стандартной.
Теперь вернемся к Transparent Page Sharing. Во-первых, подумайте - сколько дубликатов страниц вы найдете, если размер страницы увеличился в 500 раз? Наверное, процент этих страниц будет очень и очень близок к нулю. Во-вторых, по заверениям Microsoft (объяснявшей возможности функций Dynamic Memory в новой версии Hyper-V), процесс исследования двухмегабайтовых страниц памяти побитно, их хэширование и сохранение в таблице учета дубликатов может занять часы!
Данные факты подтверждаются и сотрудником самой VMware, который говорит о том, что ESX не трогает большие страницы:
The only problem is that when large pages is used, Page Sharing needs to find identical 2M chunks (as compared to 4K chunks when small pages is used) and the likelihood of finding this is less (unless guest writes all zeroes to 2M chunk) so ESX does not attempt collapses large pages and thats [sic] why memory savings due to TPS goes down when all the guest pages are mapped by large pages by the hypervisor.
Понимаете о чем это? Это о том, что технология Transparent Page Sharing в ее нынешнем виде может умереть...
Зачастую бывает необходимо понять причины, по которым та или иная виртуальная машина на сервере VMware ESX испытывает проблемы производительности (тормозит). Можно воспользоваться встроенными графиками производительности VMware vCenter (вкладка Performance), однако этого может оказаться недостаточно. В консольной ОС VMware ESX (Service Console) есть утилита esxtop, которая позволяет отслеживать все аспекты производительности сервера виртуализации, а для VMware ESXi доступна утилита resxtop, которую можно запустить с помощью VMware vSphere Management Assistant.
Компания Veeam Software известна своими продуктами для управления и автоматизации виртуальной инфраструктуры VMware VI / vSphere. Флагманский продукт компании Veeam Backup для резервного копирования инфраструктуры виртуализации VMware vSphere уже завоевал популярность не только на Западе, но и в России (банки, телекоммуникационные компании), а вот про Veeam Monitor я хотел бы сегодня рассказать отдельно, потому как это единственное в своем роде качественное средство централизованного мониторинга хостов VMware ESX.
Одна из замечательных технологий, которая стала доступна из GUI в VMware vSphere, Storage VMotion позволяет перемещать хранилище виртуальной машины (ее виртуальные диски) на другой том VMFS / LUN без остановки работы служб и приложений.
На диаграмме ниже показано, какие именно фазы проходят в ESX / ESXi при перемещении виртуальной машины между хранилищами.
Компания VMware имеет проприетарную технологию Transparent Page Sharing в платформе VMware ESX / ESXi, которая позволяет более эффективно расходовать RAM хоста.
Что такое Transparent Page Sharing у VMware ESX / ESXi? Это механизм поиска одинаковых страниц в оперативной памяти гостевой ОС виртуальной машины, при котором в случае нахождения одинаковых страниц, вместо копии вставляется ссылка на оригинальную страницу памяти. Тем самым сокращается необходимое количество RAM на хосте ESX / ESXi.
Компания VMware говорит о том, что механизм Transparent Page Sharing сокращает требуемое количество памяти на хосте ESX / ESXi на величину от 5 до 30 процентов в зависимости от задачи (чем однотипнее задачи в виртуальных машинах – тем больше одинаковых страниц и больше экономия). По умолчанию Transparent Page Sharing включен на хостах ESX / ESXi.
А теперь о недостатках Transparent Page Sharing... Таги: VMware, ESX, ESXi
Сегодня для многих пользователей актуальны «переносные» виртуальные машины на USB флэш-накопителях, которые можно запускать на любом компьютере. Такой вариант использования виртуальных машин очень перспективен и сегодня мы поговорим о том, как улучшить производительность таких ВМ для VMware Workstation, Server или ACE. Таги: VMware, Workstation, Server, ESX, Storage
Если вы запустили VMware ESXi с флэшки и решили лицензировать его как VMware Virtual Infrastructure Standard, то может случиться такая ситуация, когда HA-агент не хочет конфигурироваться и выдает ошибку на панели задач VMware VI Client:
An error occurred during configuration of the HA agent of the host.
На вкладке «Tasks & Events» вы увидите следующее сообщение:
HA agent has an error : Host in HA Cluster must have userworld swap enabled
Это случается, из-за того, что userworld swap (uwswap) для самого ESXi не сконфигурирован и хост не может быть добавлен в HA-кластер. Как решить эту проблему... Таги: VMware, ESXi, HA
Оптимизация виртуальных систем под управлением платформ VMware Server и VMware Workstation состоит из четырех ключевых компонентов:
правильный выбор аппаратного обеспечения и его оптимизация
настройка и оптимизация хостовой платформы
настройка и оптимизация платформы виртуализации и виртуальных машин
оптимизация гостевой системы
Только при соблюдении рекомендаций VMware по оптимизации производительности с учетом этих компонентов можно получить по-настоящему эффективно и быстро работающие виртуальные системы.
Недостаточно просто установить гостевую систему в виртуальной машине, нужно также произвести ее базовую оптимизацию в целях наибольшей эффективности использования. Основные рекомендации по повышению производительности приведены в этой статье.
RSS
